Skip to content

Conversation

lolbinarycat
Copy link
Contributor

I had a thought randomly that we could reduce the amount of times lib_embargo_visit_item is called by only calling it when we want to get the effective visibility of an item in a given crate, since DefId contains a CrateNum. However, this could require some fairly complex locking, so I thought I should instrument this pass to get a ceiling of how much performance gain this could give.

If this would make a difference ever, it would be in crates with a large number of dependencies that are never referenced from the docs (no intra-doc links, trait impls, or re-exports)

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. labels Oct 7, 2025
@lolbinarycat
Copy link
Contributor Author

@bors2 try @rust-timer queue

@rust-timer

This comment has been minimized.

rust-bors bot added a commit that referenced this pull request Oct 7, 2025
…, r=<try>

rustdoc: instrument call to lib_embargo_visit_item
@rust-bors

This comment has been minimized.

@rustbot rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Oct 7, 2025
@rust-bors
Copy link

rust-bors bot commented Oct 7, 2025

☀️ Try build successful (CI)
Build commit: 3ddbf8e (3ddbf8e974f049e8c24d6740d3278050789cc95c, parent: 4a54b26d30dac43778afb0e503524b763fce0eee)

@rust-timer

This comment has been minimized.

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (3ddbf8e): comparison URL.

Overall result: ❌ regressions - no action needed

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
0.7% [0.7%, 0.7%] 1
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) - - 0

Max RSS (memory usage)

This benchmark run did not return any relevant results for this metric.

Cycles

Results (secondary 1.9%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
1.9% [1.9%, 1.9%] 1
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) - - 0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 473.216s -> 472.682s (-0.11%)
Artifact size: 388.39 MiB -> 388.37 MiB (-0.00%)

@rustbot rustbot removed the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Oct 7, 2025
@lolbinarycat
Copy link
Contributor Author

for crates with many dependancies (ripgrep, large-workspace), this phase accounts for around 1.5% of runtime.

we also don't have any truly massive doc bundles like zed in the test suite.

I think a 0.5%-1% improvement is likely possible and may be worth pursuing. this could be done either by via parallelism or by only generating that data on demand.

@lolbinarycat
Copy link
Contributor Author

well, TyCtxt is !Send, so that makes this a lot harder...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants